The present invention generally relates to, in general, to assessing application errors and error symptoms in a computing environment, and in particular, to objectively assessing application errors and error symptoms from a customer computing environment.
As information technology capabilities have increased steadily due to improvements in technology and practices, organizations have grown increasingly reliant on the information technology infrastructure to support critical organization processes and to create new opportunities. One primary business use of information technology often occurs through software applications. Thus, maintaining reliable and available software application is important to supporting efficient business processes and fostering improvements in these processes.
Network administrators typically manage the maintenance and improvement of software application performance for the computing devices on the organization network. Maintaining reliable and available software applications is largely a matter of monitoring the errors and error symptoms, evaluating that against expected norms, and generating work items to troubleshoot and/or improve the errors and error symptoms based on the evaluation.
Because organizations typically have many computing devices having numerous software applications, monitoring the performance can be a difficult task. Many users of computing devices fail to report errors and error symptoms to network administrators. Even when users report errors and error symptoms to network administrators, the reports are often vague or unsure as to what the user was doing or which software applications they were using when an error or error symptom occurs. Thus, obtaining accurate software application error data within an organization network can be especially difficult.
Where accurate error data is collected, evaluating the error data requires understanding the relationship between the data collected and the error that occurred. In many conventional practices, error data is merely reported as a file name which may be meaningless to network administrators or requires research in order to understand the relationship to the error that occurred.
Even where the context of the error data is understood, an evaluation of the error data requires compiling and sorting the data. For a large organization, compiling and sorting error data for the computing devices on the organization network is a large and time consuming task. Moreover, error data collected from a given network, does not provide network administrators with an understanding as to whether the software is performing at a normal level. Such an understanding is achieved with information relating to occurrences of errors and error symptoms in other organizations in the industry and allows organizations to diagnose and assign priority to troubleshooting and improving software application performance.
For example, where a network administrator learns that a particular software application is experiencing large numbers of errors across the organization's network, a comparison of errors occurring with the software application in other organizations in the industry allows a network administrator to determine whether the errors maybe caused by the software application itself or whether they maybe caused by an issue unique to the organization's network. In addition, where a network administrator is considering deploying a software application update or upgrade, accessing error data for the particular software application in other similar organization networks provides the network administrator with insight as to the effect the update or upgrade will have on his organization's network.
Implementing solutions and preventing future software errors and their symptoms is a constant goal for network administrators. In large organizations where many errors are reported, identifying or developing solutions quickly and efficiently can be a challenge for network administrators. While conventional practices aid in identifying selected solutions currently available for a particular error to the user, a significant number of errors are not resolved by these practices. Often, users do not implement the identified solutions because they do not understand how or do not wish to take the time. Additionally or alternatively, many solutions are not developed until after the error occurs and conventional practices fail to identify subsequently developed solutions to users.